version: 2022062401
在講專案管理前，我先講個小故事在2021年時我打算買房子，所以我看了140間的房子。有次我跟一個預售屋建案的工地主任聊天，我就提問: 「請問你(工地主任)都是怎麼判斷你顧用的工程人員，專業能力是否符合工地需求?」
他用肯定的眼神回答:「細節」。

工地主任指是的做工的細節，就可以判斷這個工程人員，施工的品質。

*你好，如果你是管理職的人員，可以直接跳到「分數表」，直接套用做程式人員管理。

這個管理思維跟軟體專案管理不謀而合
以下就程式碼判斷程式設計師的「施工品質」
在開發大型專案時，大多會組建五人以上的團隊。依照各個專業人士下去分工，且專業人士完工後回報給專案經理，

分析的程式碼的三個重點:
1) 變數命名
2) 註解
3) 程式碼的結構
A. 防呆(輸入資料型別、極大值、極小值)
B. 處理(Big O)
C. 輸出

1. 變數命名，例如

是否有依照「國際的命名規則」命名變數名稱，像是Java 就有固定的命名規則，像是變數的話Java 採取小寫駝峰(lower camel case):

String setUpNetworking = “”; //建議的寫法
String aa = “”; //不建議的寫法

2. 註解
   有良好習慣的程式設計師都會寫註解。因為寫完程式後，大約二個星期內就會完全忘記自已寫的程式，所以有經驗的且受過良好訓練的程式設計師，都會在「關鍵」的程碼寫下「註解」。
   例如 kotlin 寫法:

val apktxtIp = “”//存放apk txt網址
//判斷外部儲存空間是否可寫入
private fun isExternalStorageWritable():Boolean{
}

3. 程式碼的結構
   A. 防呆: 先把傳入的資料進行極大值、極小值、型別的判斷、型別轉換，用來防止程式碼進行 B.處理 時發生無法預期的錯誤。
   例如 C++寫法:

string greatestLetter(string sInputString){
 if(sInputString.length() > 1000 || sInputString.length() < 1)
 return “Error Input String.”;
}

B. 處理(Big O): 程式碼進行運算處理的部份，一般不建議把for迴圈寫到BigO n的四次方以上，因為這樣寫出來的程式就算能正常運作，此程式碼的處理的效能會太慢而被放棄使用。基本上多重for(){ for(){}} 迴圈越少圈越好。當然還有其他的部份像是OOP(Object-oriented programming), List之類的結構化程式碼寫法。
例如 C++ 2層for，程式的運作效能還行:

for(int i =0; i < iLength ;i++){
  for(int j =0; j < iLength ;j++){
  	/*處理過程*/
  }
}

C. 輸出: 就是當你的程式已經處理完後，要用什麼型別回傳值給其他程式作運用。這部份的工作就比較像是系統架構師(SA)、資深程式設計師會做的工作，規劃各個程式之間的溝通介面(Interface)。依照專案的不同，可能回傳List, JSON format之類的，分辦的重點在於介面的可擴充性，以後回傳值是否會有增加、減少的狀況來做討論。
例如:

public List<Integer> convertListToMap(List<T> listIn){
 return result;
}

分數表:
可以依照上述的判斷做一個標準，製作成一個分數表。如下
*裡面的數字可以依照專案團隊的需求而改變。

結論:
一個系統專案的成功要有許多要素的構成，才能在期限內完成交件的任務。

寫程式的能力是程式設計師最基本的門檻，
所以才要用上面的表格去分辨程式設計師的撰寫程式的程度，正常情況專案經理，會要求的是能實戰寫程式的人員，因為大部分的求職者都不會寫程式。

在過去十六年開發專案時我遇過多種的狀況，像是兩個程式設計師個性不合互相打架，我也有遇過寫一支程式寫兩個月寫不出來的程式設計師，或是個性固執且無法跟團隊合作的程式設計師，各種情況都有。
以上是我的專案經驗分享，希望這些資訊對你有用。

如果有事情找我，請到Linkedin，謝謝
轉貼政策:著明作者 Billour Ou 歐育溙 就可以自由轉貼。

關於作者:
Billour Ou
歐育溙 的資歷

簡歷:
Google Technical Lead 面試邀請
Yahoo bid, 百萬成功賣家
台灣教育部 DSP 競賽全國, 第一名